A variety of software applications create log files that keep a record of error conditions that have been detected. For example, an application that refers to an external file for configuration information may generate an error notice that is recorded in a log file associated with the application if that external file is determined to be missing or corrupt. Early identification of such error conditions allows remedial action to be taken that can minimize or eliminate the impact of these errors on a business being supported by the application. Hence, such log files are often monitored as part of a continuing production support environment.
As a practical matter, it is difficult and inefficient to have IT personnel continuously monitoring these log files, particularly in a large enterprise. Consequently, it is desirable to automate the monitoring process so that the appropriate personnel will be notified of any error conditions detected.
One complicating factor in this effort is that some applications create a series of log files in the form of a circular buffer. In such a configuration, the oldest file in the buffer is periodically deleted and is replaced with a file containing the newest information. The current or most recent log file will often have a standard name, and the previous log files will have derivative names based on the standard name. Such a configuration is often employed because it allows convenient access to the most recent data.
Unfortunately, the creation of the new standard log file by applications that utilize circular buffer log file configurations is not always predictable. In some instances, for example, the new standard log file is created only when a previous file has reached a certain size. Consequently, if attempts are made to access the log file for the purpose of implementing an automated monitoring process, these attempts may result in an older version of the log file being accessed, which in turn may result in lack of notification with respect to more recent error conditions. On the other hand, if the automated monitoring process is simply configured to look for the most recent log file, error events that have happened between successive iterations of the monitoring process may go undetected. As an added complication, if the monitoring process fails to adequately distinguish unreported error conditions from those that have already been reported, duplicate error notifications will be generated, thus resulting in the misapplication of IT resources.
Some conventional system management tools are configured to monitor log files by opening the file, reading and scanning the log file, sending out appropriate notifications, and then going into a sleep mode. After a certain period of time, the process wakes up to continue reading the log file. This type of approach utilizes the file system behavior to keep track of the file pointer position between sequential reads within a single program execution.
However, while such an approach is potentially capable of avoiding problems of the type noted above, this approach requires that the system management tool operate somewhat continuously in the background. Hence, programs of this type can consume a significant amount of system resources and bandwidth.
To date, some standard utilities, such as the GREP (Global Regular Expression Print) utility in UNIX, are capable of scanning files for occurrences of a specified string of characters. Every time it finds a line that contains the specified strings, it displays the line on screen. If it is searching through more than one file; it also notes the name of the file in which the string occurred. The user specifies which files to search through and which strings to look for.
The GREP utility, which may be run in the background, is utilized primarily to find one or more files which contain a known string when the name of the file containing the information is unknown. It can be utilized to check all the files in a directory or a single file. GREP has been utilized by software developers to search for known error conditions in build files.
In searching build files, GREP and other traditional search tools typically produce all potentially relevant hits, but leave it up to the user to determine which ones are real and what can be ignored. Such utilities could potentially be used to detect the presence of a certain character string (corresponding to a specific error message) in a log file for the purpose of monitoring these files. However, the use of such utilities becomes impractical when multiple character strings must be detected.
Other methods of conducting error log analysis have been developed and are disclosed in the literature. For example, one method has been disclosed for diagnosing faults in a computer-based system. In that method, a log of errors of different kinds that have been recorded in the system is read, and errors of those kinds that are relevant to one or more predetermined types of faults that can occur in the system are selected from the log. The selected errors are filtered so as to compose one or more events, each event comprising one or more occurrences of one or more of the relevant kinds of the errors. The composed events are analyzed to reach an assessment that at least one of the predetermined types of faults has occurred. In preferred embodiments of the method, an error log analyzer (ELA) scans error logs generated by a computer system. The logs are preferably generated whenever the system is running and are analyzed by the ELA at regular intervals and/or when a fault has occurred.
Another method of conducting error log analysis that has been disclosed in the literature relates to identifying predefined error conditions in a build output log file to determine if software build is defective. In accordance with the method, an output log file is generated within a storage device of a data processing system during a build of a software algorithm on the data processing system. A user creates a list file on the data processing system containing predefined valid error conditions. The output log file is searched to identify user-defined strings from the list file. A comparison of the user-defined strings identified during the search is made with predefined valid error conditions to determine when the user-defined strings identified matches the predefined valid conditions.
While the two methods described above may have some desirable attributes, they do not address the aforementioned problem concerning circular file buffers. These methods also do not describe a means by which the consumption of system resources by the error log monitoring process may be minimized.
There is thus a need in the art for methods for monitoring error log files of the type generated by software programs, which methods overcome the above noted infirmities. In particular, there is a need in the art for methods for monitoring error log files, and for software programs and systems which implement these methodologies, in which notice of all reportable error conditions in the error logs of software supporting a business is provided to the appropriate support personnel, and in which duplicative notices are avoided. There is further a need in the art for such methods, software and systems that can accommodate applications that utilize circular file buffers, and that can readily detect multiple character strings in error log files. There is also a need in the art for methods, software and systems of this type which minimize the use of system resources in the monitoring process. These and other needs are met by the methods, software and systems disclosed herein and hereinafter described.